El principio de responsabilidad única nos dice que cada clase debe de tener una única responsabilidad, dicho de otra manera, cada clase solo puede tener una razón para cambiar.
Si tenemos una clase como la siguiente:
Class Modem
{
public void dial(String pno);
public void hangup();
public void send(char c);
public char recv();
}En esta clase tendríamos 2 responsabilidades, las funciones que se encargan de realizar la conexión (dial y hangup), y las funciones que se encargan de transmitir los datos (send y recv), en este caso podríamos separar dichas funciones en dos clases como DataTransmision y Connection.
De todas maneras no siempre tenemos que separar las responsabilidades, tendríamos que realizar dicha separación solo si el diseño de la clase es susceptible de ser cambiado en el futuro, de este modo solo tendríamos que cambiar la responsabilidad que es afectada, pero si el diseño no es susceptible a cambios no debemos de separar las clases, ya que en ese caso estaríamos introduciendo una complejidad innecesaria en el diseño.
Explicar complejidad innecesaria y como se aplica el principio solo cuando hay posibilidades de que ocurra un cambio
Otro ejemplo comun en el que debemos de separar una clase en varias es cuando manejamos persistencia un error muy común es el siguiente:
Class Empleado
{
calcularPago();
almacenar();
}En este caso es importante separar las dos responsabilidades, por un lado la que se encarga del almacenamiento y por otro la que se encarga de calculos, ya que una (la del almacenamiento), es muy poco susceptible a recibir cambios pero la de calculo es mas susceptible a cambiar, por lo tanto todos los cambios que se hagan sobre calcularPago estarían afectando a almacenar, ya que están dentro de la misma clase, esto implicaría por ejemplo retestear todas las clases que utilicen la función almacenar incluso aún cuando esta no haya sufrido cambios
SOLID | Single Responsibility